home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19951130-19960209 / 000455_news@columbia.edu _Mon Feb 5 13:09:59 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.3/8.7.3) with ESMTP id NAA08010 for <kermit.misc@watsun>; Mon, 5 Feb 1996 13:09:56 -0500 (EST)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.3/8.7.3) id NAA21959 for kermit.misc@watsun; Mon, 5 Feb 1996 13:09:53 -0500 (EST)
  4. Path: news.columbia.edu!panix!imci5!suck-feed.internetmci.com!news.internetMCI.com!newsfeed.internetmci.com!swrinde!sgigate.sgi.com!wrdis02.robins.af.mil!rcp6.elan.af.mil!newshub.nosc.mil!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd
  5. From: jrd@cc.usu.edu (Joe Doupnik)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: Ctrl-C Seen Where No Ctrl-C Entered
  8. Message-ID: <1996Feb3.083812.73115@cc.usu.edu>
  9. Date: 3 Feb 96 08:38:12 MDT
  10. References: <4eue8l$o8t@Jupiter.mcs.net>
  11. Organization: Utah State University
  12. Lines: 51
  13.  
  14. In article <4eue8l$o8t@Jupiter.mcs.net>, heiby@falkor.chi.il.us (Ron Heiby) writes:
  15. > I am running a copy of MS-DOS Kermit which identifies itself as "3.14
  16. > 18 Jan 1995 patch level 0" on a Dell 486SX/25 in a Windows 3.1 DOS
  17.  
  18.     That initial release was replaced by the 21 May edition and
  19. attendent patch files. Please see kermit.columbia.edu, directory
  20. kermit/msdos, archive file msvibm.zip.
  21.  
  22. > window. I am running a copy of OS/2 "C-Kermit 5A(191), 24 Apr 95" on a
  23. > ThinkPad 755CE (486DX/100) under OS/2 Warp 3.0. Between these two is a
  24. > serial cable which came with the FastLynx software package (and with
  25. > which I have never had any trouble.
  26. > 
  27. > What I would like to do is to put the MS-Kermit into "server" mode,
  28. > and conduct all of the operations from the OS/2 session. For the most
  29. > part, this seems to work. However, I have noticed that when I attempt
  30. > to send large binary (.ZIP) files from the OS/2 to the DOS version,
  31. > after just a (smallish) portion of the file is transferred (with a
  32. > "put" command), the transfer is halted with messages to the effect
  33. > that I have aborted the transfer with a Ctrl-C. Nothing could be
  34. > further from the truth. Yesterday, I attempted such a transfer several
  35. > times with identical results. Today, I attempted such a transfer with
  36. > a different file, again with these results.
  37. > 
  38. > I have discovered a workaround. When I give up "server" mode on the
  39. > DOS kermit and use "REC" there and "SEND" on the OS/2 side, the
  40. > transfer goes to completion normally, and all is well.
  41. > 
  42. > I'd appreciate being told what I am doing wrong, where I can get a
  43. > fixed version of whichever Kermit is acting up, or any other helpful
  44. > suggestions or questions.
  45. ----------------
  46.     That "stray" Control-C effect isn't built into the Kermit software.
  47. If the DOS machine has IRQ/port conflicts wierd things will happen. If
  48. the serial port speed is set to very high speeds and the UARTs plus cable
  49. are not all they should be then bytes can be clobbered now and then, and
  50. some can end up looking like Control-C. If you have a virus or other helpful
  51. programs watching the keyboard then unusual results can happen. Do watch for
  52. comms outages resulting when disk cache programs dump large amounts of data
  53. to disk. And so on down the usual list of gotcha's.
  54.     Direct serial communications requires adequate flow control between
  55. machines. That's conventionally XON/XOFF. RTS/CTS may or may not work,
  56. depending on whether your serial cable has all the wires it ought.
  57.     Then there is the OS/2 side of matters. You controlled the file
  58. transfers from there, and trouble with serial comms could produce unusual
  59. effects too. I'm not an expert on OS/2 serial comms so I will leave detailed
  60. speculation to those who are.
  61.     As a fallback, I would try with lower serial port speeds to unstress
  62. the comms link, and I would not try unprefixing control codes in Kermit
  63. packets.
  64.         Joe D.